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EXECUTIVE  SUMMARY 

Current  Federal  Aviation  Administration  (FAA)  regulations  allow  all  nonprecision 
and  precision  Category  I  and  Category  XI  approach  and  landing  operations  to 
include  a  transition  from  instrument  flight  rules  to  visual  flight  rules, 
followed  by  a  "fly  visual"  segment  to  complete  the  landing.  As  a  means  for 
increasing  airport  capacity,  numerous  "fly  visual"  concepts  have  been  envisioned; 
simultaneous  charted  visual  approaches  to  closely  Bpaced  parallel  runways, 
simultaneous  instrument  approaches  to  closely  spaced  runways,  simultaneous  visual 
approaches  to  intersecting  runways,  and  simultaneous  converging  instrument 
approaches  to  intersecting  runways.  To  date,  very  little  qualitative  and 
quantitative  data  are  available  for  use  in  evaluating  the  safety  of  these 
concepts. 

The  Standards  Development  Branch  (AVN-540),  at  the  Mike  Monroney  Aeronautical 
Center,  Oklahoma  City,  requested  that  data  be  collected  to  be  used  to  formulate 
criteria  for  conducting  simultaneous  visual  operations  to  parallel  runways  having 
spacing  less  than  established  standards  and  to  converging  runways.  The  Dual 
Sensor  Receiver  and  Processor  (DUALSRAP)  data  collection  system,  previously  used 
to  collect  data  at  the  Chicago  O'Hare  International  Airport  (ORD)  and  San 
Francisco  International  (SFO)  was  modified  to  collect  the  necessary  data.  The 
system  used  position  reports  generated  by  the  Airport  Surveillance  Radars  (ASR-7, 
ASR-8)  along  with  their  associated  secondary  radars,  the  Air  Traffic  Control 
Boacon  Interrogators  (ATCBI-4,  ATCBI-5).  Data  were  collected  on  arriving 
targets-of-opportunity  to  Lambert-st.  Louis  International  Airport  (STL).  These 
arriving  aircraft  had  to  be  equipped  with  Mode  C/S  transponders  while  conducting 
Localizer  Directional  Aid  (LDA)  approaches  to  runways  12L  and  30L,  and  approaches 
to  runways  06,  12L,  12R,  24,  30L,  and  30R.  The  data  collection  began  August 
1990,  and  continued  until  October  1990,  when  the  required  number  of  approximately 
3000  tracks  had  been  recorded.  Voice  recordings  of  all  communications  between 
observed  aircraft  and  air  traffic  control  (ATC)  were  also  obtained,  along  with 
accurate  and  timely  weather  data. 

Data  extraction  and  reduction  was  performed  at  the  FAA  Technical  Center, 
resulting  in  smooth  track  files  and  various  plots  of  the  data.  The  reduced  track 
data  files  and  their  plots  were  forwarded  to  AVN-540.  A  Master  Database  was  also 
generated  containing  pertinent  data  related  to  track  identification  and 
environmental  conditions  considered  important  to  the  analysis.  A  limited  data 
analysis  was  performed  at  the  FAA  Technical  Center  in  order  to  determine  the 
overall  accuracy  of  the  collected  data.  AVN-540  will  conduct  the  final  analysis 
of  the  reduced  data  and  report  on  their  findings  and  recommendations. 
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^INTRODUCTION 


This  report  describes  the  data  collection  and  reduction  methodology  that  waB 
employed  to  provide  the  Standards  Development  Branch,  AVN-540,  with  the  data  they 
requested.  These  data  were  part  of  an  operational  test  and  evaluation  of  the 
visual  segment  of  approaches  to  runways  12L  and  12R,  30L  and  30R,  06  and  12L,  and 
24  and  30L  at  Lambert-St.  Louis  International  Airport  (STL).  This  is  intended 
to  accomplish  the  following: 

a.  Describe  the  data  collection  and  data  reduction  hardware  and  software. 

b.  Specify  the  data  collection  and  data  reduction  procedures. 

c.  Describe  the  deliverables  provided  by  ATC  Technology  Branch  (ACD-340). 

d.  Diecusa  general  conclusions  derived  from  preliminary  ACD-340  data 
analysis. 


e.  Provide  the  milestone  project  schedule. 

1.1  OBJECTIVES. 

The  objective  of  this  effort  was  to  provide  an  accurate  database  of  the 
navigational  accuracy  of  aircraft  flying  the  visual  approaches  to  closely  spaced 
parallel  and  intersecting  runways  at  STL  under  different  environmental 
conditions.  This  database  will  be  used  by  AVN-540  to  determine  the  acceptability 
of  certain  fly  visual  approach  and  landing  operations  associated  with  operations 
conducted  under  Instrument  Flight  Rules  (IFR) .  The  database  will  also  be  used 
to  develop  criteria  for  use  in  determining  the  operating  minimums,  operational 
criteria,  and  operational  procedures  related  to  these  operations. 

1.2  . BACKGROUND . 

Airport  capacity  remains  a  critical  issue  for  the  Federal  Aviation  Administration 
(FAA) .  The  ability  of  a  highly  active  airport  to  operate  at  its  optimal  capacity 
is  crucial  to  dally  operations,  one  method  to  maintain  airport  capacity  is  to 
permit  separation  based  on  the  fly  visual  concept  during  the  final  segment  of  the 
approach.  Operations  baaed  on  IFR  separation  have  not  accommodated  the  capacity 
requirements  at  specific  airports.  The  increases  in  traffic,  plus  the  limited 
number  of  parallel/  and  converging  runways  where  simultaneous  IFR  operations  can 
be  applied,  have  led  to  the  increased  use  of  the  fly  visual  concept  in 
operations.  The  fly  visual  concept  provides  standard  IFR  separation  until  the 
aircraft  arrive  at  a  point  where  visual  separation  must  be  established  by  either 
the  pilots  or  the  controller.  In  simultaneous  fly  visual  operations,  this 
usually  occurs  just  prior  to  arriving  at  the  point  where  the  two  flightpaths 
converge  to  the  required  minimum  IFR  lateral  separation  distance.  Very  little 
qualitative  and  quantitative  data  are  available  to  be  used  to  evaluate  the  safety 
of  numerous  fly  visual  concepts.  These  concepts  include  simultaneous  instrument 
approaches  to  closely  Bpaced  runways,  simultaneous  visual  approaches  to  closely 
spaced  runways,  simultaneous  visual  approaches  to  intersecting  runways,  and 
simultaneous  converging  instrument  approaches  to  intersecting  runways.  Flight 
standards  are  needed  to  establish  criteria  and  operational  requirements  necessary 
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to  safely  conduct  thaaa  operations  for  closely  spaced  parallel  runways  which  have 
a  fly  viaual  segment  (based  on  visual  separation) ,  as  well  as  to  converging 
runways  (Hasman,  1989). 

2.  RBLAXEP  fRWBCTS  MB  fifigHMBmilSB- 

A  work  effort  conducted  by  ACD-340,  under  the  Capacity  Studies  project ,  P20-06A, 
resulted  in  the  development  and  employment  of  the  Dual  sensor  Receiver  and 
Processor  (DUALSRAP)  Data  Collection  System.  The  DUALSRAP  System  collected  data 
from  a  Sensor  Receiver  and  Processor  (SRAP)  which  was  connected  to  the  source  of 
radar  data.  The  source  consisted  of  an  Airport  Surveillance  Radar  (ASK) -7  and 
an  ATC  Beacon  Interrogator  (ATCBl)-4.  This  system  was  used  to  characterize  the 
Instrument  Landing  System  (ILS)  navigational  performance  of  a  typical  mix  of 
today's  aircraft,  and  to  determine  tha  degree  of  containment  within  several 
hypothetical  Normal  Operating  Zones  (NOZ)  smaller  than  presently  allowed.  The 
system  was  set  up  at  Chicago  O'Hare  International  Airport  from  January  through 
March  1989  to  collect  a  database  of  over  3000  simultaneous  ILS  approaches.  The 
DUALSRAP  Data  Collection  System  was  employed  by  this  project  with  some  system 
modifications.  System  modifications  included  termination  of  data  collection  at 
a  preset  time  and  modification  of  system  defaults  for  STL  data  collection. 
Additional  software  was  used  to  facilitate  automatic  start  up  of  data  collection 
and  provide  for  remote  monitoring  and  control  of  data  collection.  Additionally, 
a  local  area  network  was  installed  to  provide  the  ability  for  on-site  data' 
reduction  and  expanded  computing  power.  A  more  detailed  description  of  the 
DUALSRAP  Data  Collection  System  was  supplied  by  J.  Thomas  and  D.  Timoteo  (Thomas, 
1990). 

-  EIWSCT.lMEIffiMSPTATtQM. 

The  primary  data  for  this  study  were  radar  tracks  of  aircraft  flying  visual 
approaches  to  runways  12L  and  12R,  30L  and  30R,  06  and  12L,  and  24  and  30L  at 
STL.  Airport  diagrams  are  shown  in  figures  1  through  9.  In  order  to  extract  the 
maximum  information  from  these  data,  secondary  data  collected  included  the 
precise  weather  conditions  during  the  approach,  the  type  of  aircraft,  the 
aircraft's  beacon  code  and  identification,  and  the  approach  fix  for  each 
aircraft. 

The  project  phases  were  divided  into  data  collection,  data  extraction  and 
reduction  with  limited  analysis,  and  data  output  to  Flight  Standards.  In 
addition,  system  support  software  was  modified  as  needed  to  accomplish  the 
project  goals. 

4.  DATA  COLLECTION. 

4.1  DATA  COLLECTION  HARDWARE. 

4.1.1  Data  Collection  System  Hardware  Description. 

The  data  collection  system  was  installed  at  the  STL  Terminal  Radar  Approach 
Control  (TRACON)  (shown  in  figure  10).  It  consiBlsd  of  the  following  hardware: 
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a.  SRAP 


b.  Interface  Card  Cage  containing i 

1.  Two  SRAP  to  PC  interface  cards. 

2.  Sensor  Interface  to  PC  interfi.ee  card. 

3.  Digital  Altimeter  Setting  Indicator  (DAS!)  interface  card. 

c.  Interfacility  Data  System  Microprocessor  (IDSM)  Interface  Unit  and 
oables. 

d.  WWVB  Time  Code  Receiver  and  Antenna. 

e.  IBM  PC  XT  Computer  System  with  Expansion  Chassis. 

f.  Zenith  Z-248  Computer  System. 

g.  IQ-Plus  IBM  XT  Compatible  Computer. 

h.  Hyundai  SAM2001  IBM  XT  compatible  computer. 

i.  Two  Mountain  Filesafe  Series  7300  150  MB  Tape  Backups. 

j.  VLR-466  Voice  Logging  Recorder. 

h.  American  Power  Conversion  1200VX  Uninterruptible  Power  Supply. 

.4JUL.1  5MP.- 

The  project  SRAP  accepted  analog  signals  from  the  ASR-8  and  ATCBI-5  and  converted 
the  data  into  digital  target  reports  used  by  the  Automated  Radar  Terminal  system 
(ARTS)  IIIA  processor.  The  SRAP  consisted  of  a  Radar  Data  Acquisition  Subsystem 
(RDAS)  and  a  Beacon  Data  Acquisition  subsystem  (BDAS) .  The  RDAS  provided 
detection  of  range  and  azimuth  of  aircraft  targets  and  weather.  The  BDAS 
provided  for  the  detection  and  reporting  of  the  range,  azimuth,  altitude,  and 
identity  of  transponder  equipped  aircraft.  The  BDAS  alBo  received  data  from  the 
RDAS  in  order  to  perform  radar/beacon  target  correlation.  Data  were  output  from 
the  SRAP  via  the  Peripheral  Interface  Module  (PIM)  in  the  form  of  either  a  one, 
two,  or  three  32-bit  word  message.  SRAP  output  consisted  of  the  following 
message  types t 

Report  Type  Description 

1  Radar  only  reports  (2  wordB) 

Used  ASR  radar  video 

2  Beacon  only/radar  reinforced  beacon  reports  (3  words) 

Used  ATCBI  or  ATCBI/ASR  radar  videos 

3  Alarms  (1  word) 

Reported  SRAP  processing  errors 

4  Sector  mark  (1  word) 

Message  output  every  11.25°  of  radar  scan 
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FAA  Technical  Center  personnel  designed  and  fabricated  a  SRAP  interface  and 
control  card  set  that  served  as  an  interface  between  a  PC  and  the  SRAP.  SRAP 
data  were  obtained  from  the  PIM  using  two  50-conductor  flat  cables.  The 
interface  card  converted  32-bit  SRAP  message  words  into  the  IBM  PC  8-bit  word 
format.  The  card  read  each  complete  SRAP  message  as  quickly  as  the  SRAP  could 
send  it  (one/  two,  three  words).  Each  message  was  broken  down  in  two,  four,  six, 
or  twelve  8-bit  bytes.  An  interrupt  was  then  sent  by  the  card  to  notify  the  PC 
of  data  ready  to  send.  The  interface  card  supported  the  four  previously  defined 
SRAP  message  types.  The  interface  permitted  simultaneous  collection  of  data  from 
two  separate  ROAS/BDAS  subsystems  (SRAPO  and  SRAPl).  These  subsystems  can  be 
connected  to  the  same  or  different  radar  sources.  It  provided  the  following 
preprocessing  functions  for  each  channel! 

a.  Automatic  synchronization  with  the  SRAP  data  by  sector  marks. 

b.  Identification  of  each  SRAP  data  report  type. 

c.  Filtering  by  sector  for  report  types  1  and  2  above. 

d.  Input,  reformatting,  and  storage  of  a  complete  SRAP  report. 

e.  Hardware  interrupt  to  XT  to  request  report  transfer. 

f.  Transmission  of  report  to  XT  via  an  Input/Output  (I/O)  channel  on  a  byte 

basis. 

The  interface  incorporated  azimuth  filtering  of  the  radar  and  beacon  only/radar 
reinforced  messages  based  on  sector  mark.  Board-mounted  DIP  switches  were  used 
to  select  both  a  start  and  stop  sector.  These  switches  were  set  prior  to  each 
test  to  restrict  collected  sectors  to  those  actually  used  by  the  aircraft  during 
approach  and  landing.  In  this  way  the  amount  of  unwanted  data  were  minimized, 
thereby  reducing  the  XT  workload  and  the  amount  of  collected  data.  The  sector 
switches  could  be  changed  during  a  test  without  stopping  collection.  In  this  way 
changing  approach  configurations  were  accommodated  while  minimizing  the  amount 
of  missed  data. 

4 .1.1. 3  DASI /XT  Interface. 

DASI  data  were  collected  by  the  DASI  interface  card.  The  IBM  PC  polled  the  DASI 
interface  card  every  4.7  seconds  to  see  if  data  were  present. 

4. 1.1.4  IDSM  Interface. 

STL  interfacility  data  were  collected  via  the  Landrum  and  Brown  ARTS 
IDentif ication  Data  Acquisition  System  (ID-DAS).  The  ID-DAS  interface  consisted 
of  a  Persyst  multiport  serial  coprocessor  board,  a  distributed  communications 
processor  capable  of  running  independently  of  the  Host  PC,  and  the  ID-DAS  Fortran 
software. 
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The  computer*  used  for  data  collection  were  atandard  IBM  XT  or  AT  Compatible 
eyatema  with  a  number  of  add-on  card*.  The  IBM  XT,  IQ-PLUS,  Hyundai,  and  Zenith 
Z-248  were  located  at  the  STL  TRACON.  Two  dedicated  phone  linea  at  the  site  were 
required  for  remote  monitoring  and  control  of  data  collection. 

The  IBM  XT  ran  the  DUALSRAP  program  that  collected,  time-tagged,  and  stored  SRAP 
and  DASI  data.  Add-on  cardB  included  a  80286/80287  Turbo  card  with  onboard 
memory  cache  for  added  processing  power,  a  2  Mb  expanded  memory  board,  a  Local 
Area  Network  (LAN)  card,  and  a  2400  baud  modem. 

The  Zenith  Z-248  AT  compatible  functioned  aa  a  nondedicated  network  file  Berver. 
It  allowed  all  computers  to  access  a  common  network  disk.  The  Zenith  had  a  600 
Mb  drive  that  saved  SRAP  and  DASI  data  after  the  day's  data  collection  was 
finished.  The  Zenith  also  included  software  to  allow  on-aite  reduction  and 
plotting  of  collected  tracks  while  the  XT  continued  to  collect  data.  Add-on 
cards  included  2.5  Mb  of  extended  memory,  a  2400  baud  modem,  and  a  LAN  card. 

The  IQ-PLUS  IBM  XT  compatible  was  set  up  to  collect  interfacility  data.  Add-on 
cards  were  the  Emulex  DCP  board,  a  LAN  card,  and  a  2400  baud  modem. 

The  Hyundai  SAM2001  IBM  XT  compatible  was  configured  with  communications  software 
that  enabled  it  to  control  the  other  computers  on  the  network.  This  allowed  FAA 
Technical  Center  personnel  to  call  up  the  Hyundai  via  modem  to  monitor  and 
control  the  IBM  XT,  the  IQ-PLUS  and  the  Zenith  Z-248.  Add-on  cards  were  a  2400 
baud  modem  card  and  a  LAN  card. 

A  PC  located  at  the  FAA  Technical  Center  was  used  to  collect  the  weather  data  for 
STL. 


4.1.3 _ Bata.. Collection  Interfaces. 

Two  types  of  data  were  collected.  Aircraft  track  data  were  collected  via  the 
DUALSRAP  System.  Weather  and  pilot/controller  communications  were  collected  by 
separate  systems.  Detailed  descriptions  of  the  data  files  are  contained  in 
appendix  A. 

4. 1.2.1  DUALSRAP  Hardware  Interface. 

The  DUALSRAP  Data  Collection  System,  shown  in  figure  10  and  described  in  section 
4.1.2,  interfaced  with  the  following  hardware: 

a.  ASR-8  and  ATCBI-5  search  and  beacon  radar,  via  a  SRAP 

b.  IDSM 

c.  DASI 

d.  WWVB  Reference  Time. 

Aircraft  position  was  determined  from  target  replies  provided  by  the  STL  TRACON 
ASR-8  and  ATCBI-5.  Radar  videos  and  triggers  were  received  by  a  project -supplied 
SRAP  from  a  feed  on  the  TRACON  radar  distribution  amplifiers;  the  project  used 
the  same  raw  radar  data  used  by  the  operational  system.  The  SRAP  converted  the 
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radar  analog  data  into  digital  processed  Information  for  tha  ARTS  IlIA  processor. 
To  minimise  impact  to  the  St.  Louis  ARTS,  the  project  obtained  a  surplus  SRAP 
from  the  fAA  Depot  in  Oklahoma  City  for  stand-alone  use.  This  SRAP's  analog 
front  end  and  digital  parameter  settings  were  brought  up  to  certification 
atandards  by  STL  Airways  Facilities  personnel. 

The  STL  interfacility  data  were  collected  by  teeing  off  of  the  feeds  between  the 
ARTS  Peripheral  Adapter  Module  (PAM)  and  the  interfacility  modems.  These  data 
provided  flight  plan  information  regarding  flights  in  the  National  Airspace 
System  (NAS).  This  was  automatically  reduced  to  provide  each  flight's  beacon 
code,  aircraft  ID,  aircraft  type,  approach  fix,  and  altitude  at  the  fix.  The 
information  was  transmitted  between  the  STL  TRACON  and  the  Kansas  city  Air  Route 
Traffic  control  center  (ARTCC) (ZCK) .  For  this  data  collection,  only  STL  arrival 
information  was  extracted  and  stored  to  disk;  departures  and  overflight  data  were 
ignored. 

DASX  data  were  collected  at  STL.  'r  DASX  provided  local  digitized  barometric 
pressure. 

The  National  Bureau  of  Standards  (NBS)  WWVB  broadcast  station  located  in  Fort 
Collins,  Colorado,  was  used  as  the  data  collection's  reference  time  source.  WWVB 
time  was  received  and  processed  by  a  commercially  available  unit  with  an  accurate 
internal  clock.  This  provided  a  stable  reference  at  the  site  when  radio 
reception  was  poor.  This  time  was  used  at  the  start  of  each  data  collection 
session  to  synchronize  the  PC  internal  real-time  clock  (Disk  Operating  System 
(DOS)  time).  The  DOS  time  was  then  used  to  time-stamp  each  of  the  SRAP  sector 
reports  recorded  to  disk. 

AiAj SLt2 _ Addition*!  Interfaces,. 

Data  obtained  from  these  sources  were  not  used  by  DUALSRAP  during  the  data 
collection  process.  These  data  were  used  in  the  data  extraction  and  reduction 
processes. 

The  STL  National  Weather  Service  (NWS)  meteorological  reports  were  collected  once 
a  day  via  modem  from  the  Kavouras,  Inc.  meteorological  database  computer  located 
at  the  Minneapolis  International  Airport  (shown  in  figure  11).  Surface 
Observation  Reports  (SA)  were  normally  available  on  an  hourly  basis,  with  Special 
Reports  (SP)  given  more  frequently  when  warranted  by  rapidly  changing  weather 
conditions.  A  full  report  consisted  of  cloud  heights  and  coverage,  visibility, 
weather,  temperature,  dewpoint,  wind  direction  and  speed,  altimeter,  and  remarks. 
Remarks  were  conditions  considered  significant  to  aviation  such  as  runway 
visibility,  cloud  types,  icing  conditions,  etc. 

Voice  recordings  of  pilot/air  traffic  controller  communications  for  approach 
control,  local  control,  and  the  Automatic  Terminal  Information  Service  (ATIS) 
channel  were  made  on  a  4-channel  audio  recorder  interfaced  with  the  Granger  Link 
Microwave  System.  An  accurate  date  and  time-of-day  stamp  was  integrated  with 
each  recorded  channel.  This  allowed  searches  for  specific  portions  of  the 
recordings  on  a  time  basis. 
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FIGURE  11.  WEATHER  DATA  COLLECTION  SYSTEM 


An  ACD-340  written  8088  Assembly  language  program  collected,  time-stamped,  and 
stored  SRAP  and  DASI  data  to  disk.  Assembly  language  was  used  for  maximum  speed 
and  hardware  control.  The  program  consisted  of  foreground  and  background 
processes.  Since  DASI  data  collection  had  a  relatively  low  data  rate,  the 
background  prooess  polled  the  DASI  to  PC  interface  card  every  4  seconds.  SRAP 
data  collection  had  a  much  higher  data  rate  and  was  handled  by  the  foreground 
routine  using  hardware  interrupts.  Collected  SRAP  and  DASI  data  were  saved  into 
memory  buffers.  These  buffers  were  dumped  to  disk  when  full. 

The  DUALSRAP  system  software  was  modified  to  allow  greater  flexibility  for  remote 
operation.  The  options  that  defined  the  system  configuration  for  a  given  session 
included t 

a.  Synchronization  of  DOS  time  with  WWVB  time  at  Btart  of  data  collection 
(synchronized  for  STL). 

b.  Range  filtering  (4,  8,  16,  32,  or  64  miles)  of  collected  targets  with 
respect  to  radar  collection  (16  miles  for  STL). 

c.  Collection  of  DASI  sensor  data  (collected  for  STL). 

d.  SRAP(s)  to  be  used  (SRAP  0  for  STL). 

e.  Collection  of  radar-only  messages  for  each  SRAP;  however,  these  messages 
had  limited  use  and  required  considerable  storage  space  and,  therefore,  were  not 
collected  for  STL. 

f.  Termination  of  data  collection  at  a  preset  time  each  day  (2200  hours  for 
STL). 

g.  Specification  of  Start  and  Stop  Sector  Marks  using  board-mounted 
switches. 

4.2.2  Interfacility  Data  Collection  Software. 

An  executable  Fortran  program  collected  and  stored  interfacility  data.  The 
program's  configuration  had  to  be  set  up  each  time  data  collection  was  started. 
The  ID-DAS  provided  the  ability  to  execute  the  collection  software  via  a  batch 
command.  The  batch  command  specified  a  redirected  input  file  with  the  necessary 
responses  needed  to  initialize  and  configure  the  software.  These  options  were 
set  ast 


a.  Processing  mode  =  Arrivals  only  for  STL  (options  were  all  operations, 
arrivals,  departures,  not  overflights). 

b.  Included  all  aircraft  ID's  for  STL. 
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c.  All  ARTS  interfacility  messages,  pertinent  to  XD-DAS,  were  copied  to  a 
buffer  file. 

d.  start  and  Stop  times  were  specified  for  STL  (data  collection  began 
immediately  upon  program  execution  and  stopped  at  2200  hours). 

e.  Default  output  filename  set  for  STL  (Imddhhmm.AOL  -  m  -  month,  dd  «  day, 
hh  ■  hour,  and  mm  -  minute). 

4.2.3  Weather  Data  Collection  Software. 

PC  Weather  was  a  telecommunications  program  which  accessed  the  Kavouras  Inc. 
meteorological  database.  The  software  was  set  up  to  call  up  and  log  onto  the 
Kavouras  database,  request  the  30  previous  SA  reports,  save  the  reports  to  disk, 
and  log  off  the  system.  Since  PC  Weather  was  intended  primarily  to  be  used  as 
an  interactive  program,  it  was  necessary  to  use  Extended  Batch  Language  (EBL)  to 
execute  the  program  unattended.  EBL  was  used  to  execute  the  following  actions 
in  the  weather  data  collection  program! 

a.  Dial  the  weather  database. 

b.  Enter  the  User  Name  and  Password  to  gain  access  to  the  system. 

c.  Send  the  command  "SA/STL  RPTS=30,"  which  requested  the  last  30  SA  reports 
for  STL. 

d.  Request  that  the  weather  data  be  saved  to  disk. 

e.  Log  off  the  database  and  then  exit  the  data  collection  program. 

4.2.4  Data  Collection  Support  Software. 

Various  off-the-shelf  software  packages  were  used  to  support  the  STL  data 
collection  effort.  The  support  coftware  were  supplied  by  Mountain  Computer, 
Inc.,  Fox  Software,  Inc.,  Seaware  Corporation,  Novell  Incorporated,  Dynamic 
Microprocessor  Associates,  Inc.,  and  Brightwork  Development  Inc. 

4. 2. 4.1  Autorun. 

Autorun  is  a  program  supplied  with  the  Mountain  Filesafe  Tape  Backup  software. 
The  program  executed  appointments  based  on  the  DOS  time  and  date  of  a  computer. 
Autorun  was  used  to  start  the  SRAP  and  interfacility  data  collection  each  day. 

4. 2.4.2  Foxbase. 

Foxbase  +2.10  is  a  database  management  program.  When  daily  data  collection  was 
started,  a  Foxbase  language  program  was  executed.  This  program  created  DOS  batch 
files  that  were  used  to  rename  data  collection  files,  to  set  the  attributes  of 
those  files,  and  to  delete  the  files  at  various  stages  of  the  data  collection. 
For  a  more  detailed  description  of  these  batch  files  refer  to  appendix  D  of  this 
report . 
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1.2.4 .3  ML- 

SSL  is  a  command  programming  language.  The  "Keyboard  Stack"  feature  of  EBL  was 
ueed  for  weather  data  collection.  The  "Keyboard  Stack"  allowed  for  answering 
questions  within  programs  without  operator  intervention.  Data  placed  in  the 
"stack"  was  seen  by  the  data  collection  program  during  execution  as  operator 
input.  / 

4.2.4. 4  Kovel 1  NetWare. 

NetWare  waa  used  to  set  up  the  local  area  network  for  the  IBM  XT  and  the  Zenith 
Z-248  computers  at  STL  with  the  Z-248  being  used  as  the  network  server. 

AjAilaJS _ DcAnvwhere . 

pcAnywhere  is  a  remote  access  software  package  that  provided  for  remote 
monitoring  and  operation  of  the  project  computers  via  modem  from  the  FAA 
Technical  Center. 

4. 2. 4. 6 _ NETremote. 

NETremote-t  is  a  communications  program  that  permits  a  single  computer  (Hyundai) 
in  a  LAN  to  have  control  over  any  other  computer  in  the  LAN.  This  allowed  FAA. 
Technical  Center  personnel  to  have  remote  access  to  any  project  computer  on  the 
network  through  one  phone  line. 

4.3  DATA  COLLECTION  PROCEDURES. 

After  the  data  collection  procedures  were  established,  it  was  not  necessary  to 
have  ACD-340  personnel  on-site.  Data  collection  was  monitored  and  operated  by 
ACD-340  personnel  at  the  FAA  Technical  Center. 

AjJ-ii — SRAP  Data  Collection  Procedures. 

The  SRAP  and  DASI  data  collection  process  consisted  of  various  programs  invoked 
by  a  batch  file.  The  batch  file  was  Btarted  on  the  IBM  XT  each  day  at  0600  hours 
(Central  time).  The  batch  file  initiated  the  following  procedures. 

a.  Created  DOS  batch  files  that  were  later  executed  during  data  collection 
to  rename,  set  attributes  of,  and  delete  data  files. 

b.  started  the  DUALSRAP  data  collection  program,  this  program  ran  from  the 
time  it  was  started  until  2200  hours  local  time  (Central  time  zone) . 

c.  After  the  data  collection  program  terminated,  the  names  of  the  SRAP, 
DASI,  and  message  data  files  were  changed  to  reflect  the  month,  day,  and  hour  of 
that  day's  data  collection.  The  IBM  XT  logged  onto  the  network  and  the  day's 
data  were  then  saved  to  the  network  drive. 

d.  Primary  and  secondary  tape  backups  of  the  day's  data  files  were 
performed. 
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e.  it  the  day's  data  wars  successfully  copied  to  the  network  drive,  then  the 
day 'a  data  files  were  deleted  from  the  XT 'a  hard  drive. 

f.  Reset  the  DOS  clock  to  WWVB  time  and  rebooted  the  IBM  XT. 

If  any  problems  occurred  during  data  collection  and  the  XT  had  to  be  rebooted, 
the  data  collection  batch  file  could  be  restarted  manually  by  on-site  personnel 
or  remotely  by  FAA  Technical  Center  personnel.  For  more  details  on  the  SRAP  data 
collection  procedures  refer  to  appendix  D  of  this  report. 

.3.2  Interfacility  Data  Collection  Procedures. 

The  Landrum  and  Brown  ARTS  ID-DAS  was  invoked  by  a  batch  file.  The  batch  file  was 
started  on  the  IQ-PLUS  XT  PC  compatible  each  day  at  0500  hours  (Central  time)  by 
an  appointment  scheduling  program,  Autorun.  Interfacility  data  collection 
started  1  hour  before  SRAP  data  collection.  The  earlier  start  time  accounted 
for  the  up  to  1  hour  time  difference  between  the  receipt  of  interfacility  data 
for  an  aircraft  and  the  aircraft's  arrival  time  at  the  airport.  The  batch  file 
initiated  the  following  procedures! 

a.  Checked  for  the  existence  of  old  data  files  in  the  interfacility  data 
subdirectory  on  the  IQ-PLUS  hard  drive.  If  any  files  were  present  they  were 
deleted. 

b.  Set  up  configuration  and  started  execution  of  the  interfacility  data 
collection  program.  This  program  ran  from  when  it  was  started  until  2200  hours 
(Central  time). 

c.  Backed  up  the  day's  data  to  hard  disk  and  to  the  network  drive.  The 
interfacility  data  saved  on  the  network  drive  was  backed  up  on  tape  at  the  same 
time  as  the  SRAP  data  files. 

If  any  problems  occurred  during  data  collection  necessitating  a  reboot  of  the  IQ- 
PLUS,  interfacility  data  collection  may  be  restarted  manually  either  remotely  or 
by  on-eite  personnel.  For  more  detail  on  interfacility  data  collection 
procedures  refer  to  appendix  D. 

4.3.3  Weather  Data  Collection  Procedures. 

The  weather  data  collection  process  wbb  invoked  by  a  batch  file.  The  batch  file 
was  started  on  an  IBM  compatible  computer,  located  at  the  FAA  Technical  Center, 
each  day  at  2350  hours  (Eastern  time)  by  Autorun.  The  batch  file  initiated  the 
following  procedures! 

a.  Checked  for  the  existence  of  old  data  files  in  the  weather  data 
subdirectory  on  the  computer's  hard  drive.  If  any  files  were  present  they  were 
deleted. 

b.  Set  up  configuration  and  started  execution  of  the  weather  data  collection 
program. 

c.  Backed  up  the  weather  data  to  the  PC's  hard  drive. 
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i.  DATA  PROCESSING, 

The  raw  STL  data  wars  proceaaad  at  tha  faa  Taohnical  Centar  to  raduea  it  to  a 
form  auitabla  for  analysis  by  ACD-340  and  AVN-540.  Data  files  generated  in  the 
oolleotion  and  reduction  processes  are  described  in  detail  in  appendix  A.  The 
data  extraction  and  reduction  processes  are  outlined  in  figure  12. 

5.1  DATA  EXTRACTION  AND  REDUCTION. 

5.1 1 1  _  Data  JtoBiBfclna  • 

Subsequent  to  data  collection  but  prior  to  data  analysis,  track  data  were 
extracted  from  the  raw  SRAP  and  interfacility  files  and  merged  into  a  database 
consisting  of  parallel  approaches.  The  extraction  procedure,  unpacking,  was  the 
process  whereby  radar  data,  recorded  in  a  binary  format  for  purposes  of  space  and 
efficiency,  was  converted  to  a  format  compatible  with  the  analysis  environment. 
The  unpacking  process  consisted  of  the  following: 

a.  valid  surveillance  messages  were  extracted  from  the  raw  SRAP  file;  both 
SRAP  and  interfacility  data  were  converted  to  engineering  units,  then  written  to 
fixed  format  files. 

b.  Data  were  sorted  into  individual  aircraft  track  fileB  according  to  beacon 
code,  aircraft  tracks  with  a  sufficient  number  of  scans  were  identified,  and  the 
runway  being  approached  was  determined  for  each  track. 

c.  SRAP  and  interfacility  data  were  cross-referenced  to  obtain  the  aircraft 
ID  and  the  aircraft  type  for  each  track. 

d.  One  record  for  each  track  was  appended  to  the  Master  database.  The  raw 
track  files  were  placed  into  a  session  subdirectory,  where  a  session  was  1  day 
of  the  collection  period.  For  a  description  of  the  software  used  during 
unpacking,  see  appendix  B. 

5.1.2  Parrot  Statistics. 

The  Parrot  Statistics  test  was  executed  on  the  unpacked  SRAP  data  to  assist  in 
the  calculation  of  the  radar  range  and  azimuth  biases  for  a  session.  This  teat 
was  a  series  of  programs  that  collected,  unpacked,  analyzed,  and  produced  a 
statistical  report  on  the  quantity  and  quality  of  transponder  data.  The 
transponder  data,  collected  continuously  during  each  session,  wao  received  from 
the  STL  radar  Parrot  transponder  located  approximately  7  miles  from  the  radar 
antenna.  There  was  a  time  delay  in  the  Parrot's  response  to  an  interrogation, 
causing  the  indicated  range  to  appear  to  be  approximately  45  nautical  miles 
(nmi).  The  report  had  values,  based  on  the  total  number  of  Parrot  returns,  for 
the  mean  and  standard  deviation  of  both  range  and  azimuth,  and  the  Azimuth  Change 
Pulse  ( ACP)  skewness  and  kurtosis  of  the  azimuth.  The  report  (figure  13)  was 
compared  with  previous  reports  to  determine  if  there  had  been  any  change  in  the 
radar  range  and  azimuth  mean  values.  There  were  no  significant  changes  in  the 
reported  range  and  azimuth  values  during  the  data  collection  period.  Any 
significant  change  of  these  values  would  have  entailed  adjustment  of  the  range 
and  azimuth  bias  values  for  individual  sessions.  The  consistency  of  the  reported 
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range  and  azimuth  values  for  the  Parrot  transponder  confirmed  that  the  ATCBI-5 
range  and  asirouth  biases  remained  constant  during  the  data  collection  period. 
These  biaaes  were  not  calculated  using  the  Parrot's  latitude  and  longitude 
values,  rather,  they  were  determined  empirically  from  reduced  track  data  to  yield 
reasonable  alignment  of  the  approach  paths  to  the  corresponding  runways.  Once 
the  bias  values  were  set,  they  were  removed  from  the  track  data  during  the 
translation  to  runway  origin. 

5.1.3  Data  Reduction. 

The  reduction  process  used  the  "raw"  or  unfiltered  track  files  created  by  the 
unpacking  process  and  performed  the  following  operations! 

a.  Individual  track  data  files  were  checked  for  reasonableness;  multiple 
scans  were  deleted,  altitudes  were  added  or  corrected  as  needed,  time  gaps  in 
data  were  identified,  and  pre-  and  post-gap  data  were  checked  to  see  if  they  were 
from  the  same  track. 

b.  Data  were  converted  from  (range,  azimuth,  altitude)  to  oarteeian  (x,  y, 
z)  coordinates.  Range  and  azimuth  biases  were  removed  from  the  track  data. 

c.  Data  were  filtered  and  smoothed  using  Lincoln  Laboratory  developed 
algorithms. 

d.  Interpolated  data  points  were  calculated  at  0.15  nmi  increments  along  the 
extended  runway  centerline. 

The  final  reduced  track  file  consisted  of  reports  at  0.15  nmi  increments  along 
the  extended  runway  centerline.  Each  track  file  record  contained:  Time  (the  time 
of  day  in  hours,  minutes,  and  seconds),  X  (distance  from  the  runway  threshold 
along  the  extended  runway  centerline),  Y  (deviation  from  extended  runway 
centerline),  and  Z  (altitude  above  sea  level).  X,  Y,  and  2  were  expressed  in 
nmi;  the  conversion  factor  used  was  6076  feet/nmi.  The  file  was  assembled  in 
reverse  time  order;  i.e.,  the  first  record  in  the  file  represented  the  touchdown 
point  or  the  distance  closest  to  touchdown.  Each  successive  record  was  an 
additional  0.15  nmi  from  touchdown  in  the  +X  direction.  These  track  files  were 
then  individually  plotted  and  sent  to  AVN-540  for  further  analysis.  For  a 
description  of  the  software  used  during  reduction,  see  appendix  B. 

All  track  files  for  each  session  were  plotted  as  a  group  on  one  2-dimensional  x,y 
graph  where  x  represents  distance  to  runway  touchdown  and  y  represents  deviation 
about  extended  runway  centerline.  An  example  of  this  type  of  plot  1b  shown  in 
figure  14.  The  plots  were  identified  by  the  session  (test)  number,  runway 
designation,  and  the  number  of  track  files  plotted.  A  grid  in  both  axes  was 
superimposed  on  the  plot  so  that  distances  could  be  more  easily  judged.  The  x 
scale  was  from  touchdown  to  15  nmi  out;  the  y  scale  was  plus  or  minus  1  nmi. 

5.1.4  Master  Database. 

A  Master  database  consisting  of  pertinent  information  about  each  track  and 
weather  observations  at  the  time  of  data  collection  was  produced  through  the 
unpacking  process.  Note:  the  Master  database  does  not  contain  any  radar  data. 
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Radar  statistics  using  C:\8TL\tJNPACK\S9090600.DBF 


»>  << 

Total  number  of  samples  is  12256 

Mean  value  of  RANGE  is  45.183  nmi  (274263  ft) 

Mean  value  of  AC?  count  is  3144.37  (276.36  deg) 

Standard  Deviation  of  RANGE  is  0.008  nmi  (46.7  ft) 
standard  Deviation  of  ACF  is  1.587  (0.139  deg/2.43  mr) 

or  667.6  ft  Q  45.183  nmi 
The  Skewness  of  AC?  is  0.272 
The  xurtosis  of  AC?  is  6.908 
Range  of  ACP's  is  from  3132  to  3161 
or  275.27  to  277.82  deg 
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FIGURE  13.  RADAR  STATISTICS  FOR  PARROT  TRANSPONDER 
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This  database  was  used  to  identify  tracks  for  conditions  that  need  to  be 
analysed.  For  a  more  detailed  description  of  the  Master  database  fields,  see 
appendix  C. 


S.2  DELIVERABLES . 


The  requested  track  data  and  their  plots  were  delivered  to  AVN-540.  The  format 
for  sending  the  data  was  floppy  disks.  The  floppy  disks  included  the  final  track 
files  for  each  session  and  the  Master  database.  Documentation  explaining  the 
data  were  also  sent  along  with  the  plots  created  for  each  session. 


6.1  DATA  REDUCTION  RESPONSIBILITIES. 

The  Engineering,  Research,  And  Development  Service,  ACD-340,  was  tasked  to 
collect  and  reduce  track  data  for  aircraft  conducting  visual  approaches  to  STX. 
runways  12L  and  12R,  30L  and  30R,  06  and  12L,  and  24  and  30L.  These  data  will 
be  used  by  AVN-540  to  justify  existing  procedures  and/or  specify  new  procedures 
for  these  approach  operations.  Since  AVN-540  had  expressed  the  need  to  conduct 
their  own  comprehensive  analysis  of  these  data,  ACD-340  performed  only  a  limited 
analysis  to  determine  if  the  processed  data  were  reasonable.  ACD-340 's  primary 
concerns  were  to  determine  how  well  the  data  represented  what  really  happened. 
This  section  will,  therefore,  address  the  primary  causes  of  error  found  in  the 
collected  data  and  steps  taken  by  ACD-340  to  improve  the  quality  of  the 
deliverables. 


6.2  DATA  FIDELITY. 

The  data  reduction  process  (see  section  5)  produced  a  file  of  position 
information  in  t,  x,  y,  and  z  for  each  recorded  track  where  t  was  time  of  day, 
x  was  the  distance  from  the  runway  threshold  along  the  extended  runway 
centerline,  y  was  the  perpendicular  distance  from  the  extended  runway  centerline, 
and  z  was  the  altitude  above  mean  sea  level  (m.s.l.).  These  data  were  filtered, 
smoothed  (see  appendix  A  and  Thomas,  1990),  and  interpolated  to  give  a  data  point 
at  each  0.15  nmi  increment  along  the  extended  runway  centerline.  This  was  done 
to  facilitate  the  calculation  of  statistics  at  specific  fixed  distances  from  the 
runway  threshold.  In  addition,  since  the  data  were  collected  via  an  ATC  ASR-8, 
range  and  azimuth  biases  were  removed  as  much  as  possible,  then  the  data  were 
translated  from  range,  azimuth,  and  altitude  having  an  origin  at  the  radar 
antenna,  to  x,  y,  and  z  having  an  origin  at  the  runway  threshold.  The  final 
result  was  a  collection  of  sessions.  A  session  consisted  of  the  reduced  data 
files  for  all  the  tracks  collected  in  a  day.  All  tracks  for  a  session  were 
plotted  on  a  single  graph;  they  were  also  subjected  to  a  simple  statistical 
analysis  producing  average  and  standard  deviations  about  the  extended  runway 
centerline  at  increments  of  0.15  nmi  away  from  runway  threshold.  Examples  of 
these  plots  can  be  found  in  the  Data  Reduction  section.  Details  of  the 
procedures  used  to  remove  radar  data  biases  can  also  be  found  in  that  section. 

Since  we  did  not  have  any  independent  devices  with  which  to  observe  each  track, 
such  as  a  second  radar,  the  only  way  to  judge  the  reasonableness  of  the 
positional  information  recorded  was  to  consider  the  data  just  prior  to  aircraft 
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touchdown.  St  was  known  that  ovary  aircraft  landed  on  tho  runway  surface. 
However,  the  plots  and  statistics  show  that  the  data  had  some  variance  about  the 
runway  centerline  just  prior  to  landing.  On  average  for  example,  the  standard 
deviation  at  0.4S  runi  from  touchdown  was  approximately  43  feet.  This  meant  that 
the  vast  majority  (but  not  all)  of  the  recorded  data  indioated  that  the  airoraft 
touched  down  on  the  runway  surface.  In  comparison,  the  average  standard 
deviation  for  STL  was  considerably  smaller  than  the  140-foot  deviation  found 
during  the  San  Francisco  international  airport  (SFo)  data  collection  (Richards, 
1991).  The  good  data  fidelity  can  most  likely  be  attributed  to  the  favorable 
siting  of  the  STL  radar  and  minimal  ground  clutter.  The  STL  runways  are  all 
within  l.S  nmi  of  the  radar  compared  to  over  S  miles  between  the  SFO  runways  and 
the  radar.  However,  new  problems  were  encountered  in  the  data  reduction 
processing  due  to  the  closeness  of  the  STL  radar,  and  difficulties  experienced 
with  the  interfacility  data  collection.  These  problems  are  discussed  in  more 
detail  the  following  sections. 

-6.2.1  Track  Extraction.  Problems . 

It  was  found  that  the  tracks  were  particularly  difficult  to  smooth  with  high 
fidelity  near  their  terminus  (Thomas,  1990).  Ground  clutter  produced  some 
erroneous  radar  replies  from  the  ASR-8  and  lowered  the  occurrence  of 
primary/beacon  radar  reinforcement  with  the  corresponding  ATCBI-5  surveillance 
report.  When  coupled  with  the  relatively  low  4.7  second  scan  rate,  one  or  more 
questionable  or  missing  surveillance  reports  close  to  touchdown  could 
significantly  skew  the  smooth  estimate  of  the  track  at  its  terminus,  making  the 
aircraft  appear  to  have  missed  the  runway  by  a  small  amount.  Fortunately,  most 
of  the  track  files  displayed  good  radar  data  down  to  landing.  Track  data  files 
with  problematic  radar  data  were  found  by  displaying  an  entire  session  on  a 
single  plot,  then  visually  picking  out  the  deviant  tracks.  These  tracks  were 
examined  manually;  surveillance  reports  having  more  than  a  reasonable  amount  of 
deviation  (approximately  5  sigma)  at  touchdown  were  removed  leaving  a  data  gap. 
This  data  gap  would  later  be  "refilled"  by  the  smoothing  process. 

It  was  found  in  previous  data  collections  (FAA  Technical  Center,  Chicago  O'Hare 
Internation  Airport  (ORD),  and  SFO)  that  operational  radars  typically  do  not 
report  targets  near  the  ground.  Most  sites  set  equipment  parameters  to  cutoff 
radar  coverage  when  the  range  is  less  than  about  1  nmi.  This  normally  avoids 
artifacts  Buch  as  "ring  around";  it  also  eliminates  arriving  and  departing 
flights  that  will  be  below  a  few  hundred  feet  altitude  within  1  nmi.  However, 
at  STL,  a  significant  number  of  aircraft  were  "seen"  up  to  and  well  after  touch¬ 
down.  This  "extended"  radar  coverage,  coupled  with  a  malfunction  in  the 
interfacility  data  collection,  created  a  new  reduction  problem.  When  an  arriving 
aircraft  and  a  departing  aircraft  having  the  same  beacon  code  were  active  within 
the  same  40-minute  "window,"  the  track  file  would  erroneously  contain  radar  data 
for  both  aircraft.  In  previous  data  collections  (ORD  and  SFO),  accurate  flight 
termination  times  were  obtained  from  interfacility  data  (ARTS  Terminate  Beacon 
(TB)  reports).  At  STL,  only  the  hand-eff  time  (ARTCC  to  TRACON)  could  be 
obtained  from  the  collected  interfacility  data.  This  required  a  40-minute  window 
to  be  used  by  the  reduction  software  to  account  for  the  time  between  hand-off  and 
landing.  Files  having  this  problem  were  identified  by  their  relatively  large 
size  (>  10K  bytes)  and  the  erroneous  data  removed  manually.  This  was  a  labor 
intensive,  but  very  important  step,  in  assuring  track  quality. 
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Another  factor  taken  into  consideration  were  measurement  errors  in  the  range, 
azimuth,  and  altitude  data  reported  by  the  radar  (Thomas,  1990).  Little  could 
be  done  about  altitude  errors)  they  can  be  attributed  solely  to  the  quality  and 
calibration  of  the  aircraft's  altimeter  and  are  simply  reported  to  the  ground  in 
a  Mode  c  transponder  message  to  the  secondary  radar.  Mange  and  azimuth  errors 
have  both  a  random  and  a  fixed  component,  and  are  the  result  of  radar 
measurement,  and,  in  some  cases,  the  calibration  of  the  aircraft  transponder. 
While  the  random  component  can  be  characterized,  the  fixed  component  can  normally 
be  identified  and  removed  leaving  a  higher  quality  track  file. 

Small  random  errors  that  occur  in  the  beacon  range  are  caused  by  varying  received 
signal  strength  at  thB  transponder;  signal  strength  varies  inversely  with  the 
Bquare  of  the  distance  from  the  radar,  but  can  also  be  affected  somewhat  by 
atmospheric  conditions.  This  error  is  related  to  the  transponder's  ability  to 
exactly  determine  the  edge  of  the  beacon  interrogation  pulse  even  when  the  signal 
gets  weak.  The  error  is  typically  small  compared  to  the  transponder  turnaround 
time  fixed  error  which  exists  because  of  manufacturing  tolerances.  The  allowable 
error  limit  in  the  transponder  turnaround  delay  (3.0  ±0.5  ps)  can  build  as  much 
as  a  ±245  foot  range  bias  into  the  beacon  range  report.  This  figure  was 
considerably  larger  than  the  standard  deviation  of  the  runway  lateral  deviation 
error  observed  in  STL  samples  near  touchdown.  (See  Thomas,  1990  for  information 
on  tests  conducted  on  transponder  delay  error.)  Other  random  range  errors  can 
occur  during  the  radar  reinforcement  process  in  the  SRAP  when  a  primary  report 
can  be  "correlated”  to  a  beacon  report.  Correlation  is  attempted  when  the  two 
reported  targets  are  within  a  parameter  range  (perhaps  300  feet)  of  each  other. 
Since  the  primary  radar  requires  detection  of  very  small  packets  of  reflected 
radio  frequency  (RF)  energy  at  its  antenna,  its  range  measurement  will  have 
considerably  more  random  noise  than  the  beacon  radar  which  receives  relatively 
strong  RF  transmissions  from  the  aircraft  transponder.  The  reinforcement  process 
in  the  SRAP  assumes  that  the  actual  data  point  is  somewhere  between  the  primary 
and  secondary  reported  position;  it  uses  a  weighted  averaging  technique  to 
calculate  that  point.  Therefore,  the  relatively  noise  free  beacon  range 
measurement  can  actually  be  somewhat  corrupted  by  primary  radar  noiBe  during 
reinforcement.  The  averaging  weights  are  normally  set  to  50-50  percent.  Since 
correlation  often  falls  between  60  and  70  percent,  this  effect  always  has  to  be 
dealt  with. 

Fixed  errors  occur  in  the  reported  range  primarily  due  to  imperfect  adjustments 
or  drift  found  in  the  radar  or  in  the  SRAP  equipments,  or  the  transmission  link 
connecting  them.  The  SRAP  has  bias  adjustments  for  both  primary  and  beacon  range 
to  compensate  for  these  errors;  however,  there  were  no  high  quality  "benchmarks” 
to  calibrate  the  equipment  against.  This  is  particularly  true  with  the  primary 
radar  where  "permanent  echoes"  are  placed  at  known  points,  but  these  points  are 
typically  close  to  the  radar  and  low  to  the  ground,  and  are  not  collocated  with 
the  beacon  parrot.  Since  fine  adjustment  of  the  SRAP  iB  a  very  tedious  task, 
particularly  with  the  software  tools  in  the  ARTS  available  to  assist,  extremely 
accurate  adjustment  (within  50  feet)  is  not  attempted  or  required.  Nonetheless, 
these  errors  can  be  determined  each  time  and  later  removed  from  the  data. 

The  random  component  of  the  azimuth  bias  is  related  to  the  SRAP's  ability  to 
determine  the  centroid  of  the  radar  replies  received  for  a  particular  target. 
Missing  replies  during  the  hit  count  leaves  holes  or  gaps  that  the  SRAP  has 
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difficulty  dealing. with;  an  tha  signal  strength  decreases  (at  greater  distances) 
this  generally  becomes  more  of  a  problem. 

The  fixed  component  of  azimuth  error  is  relatad  to  the  occurrence  of  the  north 
mark  (0  ACP)  with  actual  magnetic  north.  This  error  changes  over  time  as 
magnetic  declination  changes;  it  can  be  adjusted  to  the  proper  value  at  the  radar 
or  by  ucing  an  azimuth  bias  setting  in  the  SRAP.  Since  magnetic  declination 
continually  changes  with  time  (and  we  do  not  continually  recalibrate),  the  true 
north  that  we  calculate  from  the  reported  magnetic  north  will  almost  always  have 
a  fixed  azimuth  bias. 

The  azimuth  and  range  contribution  to  centerline  lateral  deviation  error  near 
touchdown  were  estimated  from  the  cosine  and  sine,  respectively,  of  the  angle 
between  the  runway  centerline  and  a  line  from  the  radar  site  to  the  runway 
threshold.  For  small  angles,  random  azimuth  error  would  be  a  more  significant 
factor  in  centerline  deviation  error  than  range  error.  As  this  angle  increased 
(up  to  90°),  range  error  would  tend  to  be  the  predominate  cause  of  centerline 
deviation  error.  The  centerline  lateral  deviation  error  was  more  significant  for 
some  runways  than  others  at  STL.  Generally  for  STL  data,  it  can  be  seen  that  the 
larger  the  range  contribution  to  the  error  at  landing,  the  greater  the  lateral 
deviation  error  for  a  given  runway  (table  1).  This  indicated  that  the  majority 
of  random  error  was  due  to  range  error. 

The  varying  range  and  azimuth  contributions  to  error  at  touchdown  were  due  to 
the  orientation  of  radar  with  respect  to  runways  06,  12L,  12R,  24,  30L,  and  30R 
(figure  15).  Taking  the  amount  of  transponder  delay  error  into  consideration, 
along  with  the  radar-runway  orientation  at  STL,  the  magnitude  of  the  random  error 
in  the  STL  data  near  touchdown  could  be  considered  reasonable.  It  must  be 
remembered  that  the  error  in  the  range  measurement,  caused  by  the  transponder 
delay  error,  resulted  in  a  random  error  for  the  data  sample  because  of  the  large 
number  of  transponders  in  the  sample,  one  for  each  aircraft.  Due  to  the  random 
nature  of  this  error,  it  is  impossible  to  reliably  remove  it. 

_ Data  Fidelity  Moving  Away  From  Touchdown. 

The  situation  of  STL  radar  coverage  at  touchdown  was  unique  due  to  target 
altitude  and  radar/runway  orientation.  STL  radar  measurement  accuracy  during  the 
approach  to  touchdown  was  a  different  situation.  The  radar  measurements  on  the 
approach  were  not  subject  to  the  problems  associated  with  low  altitude;  i.e., 
missed  and  reflected  reports,  Bince  the  target  was  always  high  enough.  However, 
the  measurements  were  still  subject  to  range  and  azimuth  errors.  Once  again  the 
radar/runway  orientation  was  the  main  factor  because  of  the  requirement  to 
determine  how  well  an  aircraft  flew  its  assigned  approach  coarse  centerline.  In 
theory,  for  all  of  the  STL  runways,  the  further  the  aircraft  was  from  touchdown, 
the  more  the  deviation  from  course  centerline  was  dependent  on  azimuth 
measurement.  Unfortunately,  it  was  difficult  to  determine  the  accuracy  of  radar 
reports  for  individual  aircraft,  because  many  aircraft  in  a  given  sample  did  not 
follow  a  straight  line  approach  to  landing.  In  all  sessions  there  were  aircraft 
that  turned  on  to  the  approach  centerline  as  close  as  1  to  1-1/2  miles  from  the 
touchdown  point. 
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TABLE  1.  RUNWAY  CENTERLINE  DEVIATION  ERROR  AT  TOUCHDOWN 


RWV 

Azimuth 

Contribution  (%) 

Range 

Contribution  (%\ 

Average  Standard 
Deviation  at  0.45  nmi 

Days  Data 
Collected 

6 

34 

66 

79  feet 

3 

12L 

25 

75 

64  feet 

10 

12R 

62 

38 

52  feet 

11 

24 

63 

37 

37  feet 

13 

30L 

68 

32 

31  feet 

12 

30R 

65 

35 

35  feet 

13 

31 


FIGURE  IS.  RELATIONSHIP  OF  RADAR  SITE  AND  RUNWAYS 


6.3  SUMMARY. 


When  considering  an  aircraft  that  had  turned  onto  and  was  flying  the  final 
approach  at  STL,  the  collected  radar  data  exhibited  some  error.  The  error  wae 
composed  of  both  a  random  component  and  a  relatively  constant  component.  The 
constant  component  was  effectively  removed  via  the  parrot  transponder  procedure 
discussed  in  section  5,  but  the  random  component  could  not  be  reliably  identified 
and  removed.  The  amount  of  error  at  touchdown  was  also  affected  by  the  radar's 
orientation  to  the  runway  (figure  IS).  It  appeared  that  the  greater  the  range 
contribution  to  the  lateral  measurement  about  the  extended  runway  centerline  at 
touchdown/  the  greater  the  random  error  for  a  given  runway  (table  1). 

7.  PROJECT  SCHEDULE  AND  MILESTONES. 

STL  data  collection  was  completed  by  October  1990.  The  requested  data  for 
August/  September/  and  October  1990,  were  delivered  in  March  1991.  In  April 
1990,  AVN-540  perceived  a  need  for  an  additional  19  days  of  data  in  September  and 
October  and  requested  that  this  data  be  processed  and  sent  out  to  them.  These 
additional  and  unforseen  requests  necessitated  that  the  planned  completion  dates 
for  data  delivery  to  AVN-540  and  the  final  report  be  pushed  back. 


Milestone  Completion  Date 

a.  Installation  and  on-site  teat  of  DUALSRAP  Data 

Collection  System  at  STL.  7/93 

b.  Start  Data  Collection  for  St.  Louis.  8/90 

c.  End  Data  Collection  for  St.  Louis.  10/90 

d.  Initial  delivery  of  STL  Database  and  Plots  to 

AVN-540.  3/91 

f.  Delivery  of  additionally  requested  STL  data  to 

AVN-540.  7/91 

g.  Publish  Technical  Note  on  STL  results.  10/92 
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LIST  OF  ACRONYMS 


ACP 

ARTCC 

ARTS 

ASR 

ATC 

ATC3I 

ATXS 

ACP 

BOAS 

DASI 

DOS 

EBL 

FAA 

ID-DAS 

IDSM 

I  PR 

ILS 

I/O 

LAN 

m.s.l. 

NAS 

NBS 

runi 

NOZ 

NWS 

ORD 

PAM 

PIM 

RDAS 

SA 

SFO 

SP 

SRAP 

STL 

TB 

TRACON 

ZCK 


Azimuth  Chang*  Pulse 
Air  Rout*  Traffic  Control  center 
Automated  Radar  Terminal  System 
Airport  Surveillance  Radar 
Air  Traffic  Control 

Air  Traffic  Control  Beacon  Interrogator 

Automatic  Terminal  Information  Service 

Azimuth  Change  Pulse 

Beacon  Data  Acquisition  Subsystem 

Digital  Altimeter  system  Indicator 

Disk  operating  System 

Extended  Batch  Language 

Federal  Aviation  Administration 

IDentif ication  Data  Acquisition  System 

Interfacility  Data  System  Microprocessor 

Instrument  Flight  Rules 

Instrument  Landing  System 

Input /Output 

Local  Area  Network 

Mean  Sea  Level 

National  Airspace  System 

National  Bureau  of  Standards 

Nautical  Mile 

Normal  Operating  Zone 

National  Weather  Service 

Chicago  O' Hare  International  Airport 

Peripheral  Adapter  Module 

Peripheral  Interface  Module 

Radar  Data  Acquisition  Subsystem 

Surface  Observation 

San  Francisco  International  Airport 

Special  Report  (Weather) 

Sensor  Receiver  and  Processor 

Lambert-St.  Louis  International  Airport 

Terminate  Beacon 

Terminal  Radar  Approach  Control 

Kansas  City  Air  Route  Traffic  Control  center 
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APPENDIX  A 


DATA  PILES 

Two  types  of  data  files  are  described  in  this  appendix.  Raw  data  files  consist 
of  data  collected  in  the  field,  both  at  Lambert-St.  Louis  International  Airport 
(STL)  and  at  the  Federal  Aviation  Administration  (FAA)  Technical  Center.  Reduced 
data  files  consist  of  data  that  has  been  converted  to  a  format  compatible  with 
the  analysis  environment. 

A.-l  -  RAW.  DATA.  FILES. 

Raw  Sensor  Receiver  and  Processor  (SRAP),  Interfacility,  and  Digital  Altimeter 
Setting  Indicator  (DASI)  data  were  collected  on-site  at  STL.  Raw  weather  data 
were  collected  at  the  FAA  Technical  Center.  The  following  is  a  description  of 
the  raw  data  files  created  at  the  time  of  field  collection. 

A. 1.1  SRAP. 

The  raw  SRAP  data  were  recorded  onto  disk  using  the  filename  format  Smddhhmm.DAT: 
where;  S  »  The  letter  "S" 

m  =  The  month  (1  thru  9,  A  for  October,  B  for  November,  and 
C  for  December) 

dd  »  Day  of  month-2  digits  (01  to  31) 

hh  -  Hour  of  start  of  test  (00  to  23) 

mm  =  Minute  of  start  of  test  (00  to  59) 

From  the  raw  SRAP  file  the  following  data  was  extracted: 

a.  Time  in  hours,  minutes,  seconds  referenced  to  STL  (Central  time) 

b.  Radar  sector  number 

c.  SRAP  channel  number  (0) 

d.  Slant  range  in  nmi  from  radar 

e.  Azimuth  Change  Pulse  (ACP)  (0  thru  4096) 

f.  Azimuth  in  degrees 

g.  Quality  (0  thru  7) 

h.  Special  Position  Indicator  (SPI)  (not  used) 

i.  Beacon  code  (0000  thru  7777) 

j.  Beacon  code  validity  (0  thru  3) 

k.  Altitude  in  hundreds  of  feet  (uncorrected) 
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X.  Altitude  validity  (0  thru  3) 

m.  Beacon  hit  count 

n.  Message  type  (BO  for  beacon  only,  RB  for  radar  reinforced  beacon) 

immhQihin- 

The  interfacility  data  were  recorded  onto  disk  using  the  filename  format 
Xmddhhmm.AOL  (for  more  Information  on  "mddhhmm",  see  A. 1.1).  The  interfacility 
data  file  contained  the  following  data: 

a.  ARR  (arrival) 

b.  Time  in  hours  and  minutes  with  respect  to  STL 

o.  Beacon  code  (0000  thru  7777) 

d.  ACID  (e.g. ,  UAL923) 

e.  ACTYPE  (e.g.,  B737) 

f.  Approach  fix  (e.g.,  JOT) 

g.  Altitude  at  fix  in  hundreds  of  feet  (e.g.,  100  for  10,000  feet) 

ft 

DASI  data  were  recorded  onto  dink  using  the  filename  format  smddhhmm.RCM  (for 
more  information  on  Smddhhmm,  see  A. 1.1). 

h,  1«4  WEftTHFR- 

The  raw  weather  data  were  collected  on  an  FAA  Technical  Center  computer  by 
logging  on  the  Kavouris  Inc.  weather  data  base  and  requesting  the  day's  weather 
reports  for  STL.  The  data  were  recorded  onto  a  disk  file  whose  name  had  the 
format  WXmmddyy.TXT: 

where:  WX  -  The  letters  "WX" 

mm  »  The  month  -  2  digits  (01  thru  12) 
dd  ■  Day  of  month  -  2  digits  (01  to  31) 
yy  *  Year  -  2  digits  (00  to  99) 

TXT  -  The  letters  "TXT" 

The  weather  file  consisted  of  weather  reports,  each  report  containing  the 
following  data: 

a.  Date  in  month/day/year 

b.  Time  in  hours  and  minutes  (Zulu) 
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d.  Report  type  (SA  or  SR  or  RS) 

e.  Lowest  ceiling  type  (E  or  M  or  W) 

f.  Lowest  ceiling  height  in  hundreds  of  feet 

g.  Lowest  sky  descriptor  (OVC  or  CLR  or  BKN  or  . . . ) 

h.  Next  lowest  ceiling  type  (E  or  M  or  W) 

i.  Next  lowest  ceiling  height  in  hundreds  of  feet 

j.  Next  lowest  sky  descriptor  (OVC  or  CLR  or  BKN  or  ...) 

k.  Visibility  in  rani 

l.  weather  (rain  or  fog  or  snow  or  . ..) 

m.  Sea  level  pressure  in  millibars 

n.  Temperature  in  degrees  fahrenheit 

o.  Dewpoint  in  degrees  fahrenheit 

p.  Wind  direction  in  tens  of  degrees  referenced  to  true  north 
g.  Wind  speed  in  knots 

r.  Wind  gust  in  knots 

s.  Altimeter  setting  in  inches  of  mercury 

t .  Remarks 

Note:  for  more  information  on  these  data  refer  to  the  Aviation  Weather  Services 
Manual,  AC  00-45B,  published  jointly  by  FAA  and  NOAH. 

A. 2  DATA  REDUCTION  FILES. 

Raw  SRAP,  Interfacility,  DASI,  and  weather  data  files  were  unpacked  and  reduced 
at  the  FAA  Technical  Center.  The  following  is  a  description  of  the  Data 
Reduction  files  created  from  the  raw  data  files. 

A. 2.1  DATA  REDUCTION  TRACK  FILES. 

The  track  files  created  during  the  reduction  process  consisted  of  all  the 
position  reports  for  a  single  aircraft's  approach.  The  type  and  format  of  the 
information  contained  in  each  track  file  type  are: 


FILENAME 

MEANING 

_acid.rwy 

Datai 

MNE> 

Raw  track  file  (SRAP  0)  (output  of  TRACKS) 

HR , MN , SEC , CH , RANGE , AZMTH , BC , ALT , TYPE 

®acid.rwy 

Data: 

■■> 

Corrected  track  file  (SRAP  0)  (output  of  gap) 

HR, MN, SEC, CH, RANGE, AZMTH, BC, ALT, TYPE 

$acid.rwy 

Data: 

»■> 

GAP  documentation  file  (SRAP  0) 

list  of  missing  scans  and  altitudes  and  multiple  scans 

fiaoid.rwy 

Data: 

— > 

Translated  to  runway,  corrected  track  file  (SRAP  0)  (output 
Of  PTTRANS ) 

HR , MN , SEC , X , V , 2 

'acid. rwy 

Data: 

Smoothed,  translated,  corrected  track  file  (SRAP  0)  (output 
of  SM) 

HR,MN,SEC,X,Y,Z 

(acid. rwy 

Data: 

««> 

Interpolated,  smoothed,  translated,  corrected  track  file 
(SRAP  0)  (output  Of  INTERP) 

HR,MN,SEC,X,Y,Z 

where:  acid  «•>  Aircraft  ID  (AAL1115,  UAL100,  ...) 

rwy  ■«>  Runway  designator  (  12L,  12R,  . . . ) 

RBPVCHQN  INTPFFftCibITY  EI&B&« 

The  interfacility  data  files  created  during  the  reduction  process  consisted  of 
the  data  extracted  from  the  raw  interfacility  data  files;  however,  these  file 
data  were  converted  to  a  Foxbase  data  base  format. 

Imddhhmm.DBF  ■■>  Interfacility  data  in  a  Foxbase  data  base  format 
Datai  (See  A. 1.2) 

ft. 2. 3  DATA  REDUCTION  DASI  FILES. 

The  DASI  data  files  created  during  the  reduction  process  consisted  of  DASI  data 
extracted  from  the  raw  DASI  data  files.  The  reduced  data  files  were  converted 
to  Foxbase  data  base  format. 

Rmddhhmm.DBF  ==>  DASI  data  in  a  Foxbase  data  base  format 
Data:  Digital  Altimeter  Setting  Indicator  (DASI) 

ft. 2. 4  PATft  REDUCTION  WEATHER  FILES. 

The  weather  data  files  created  during  the  reduction  process  consisted  of  the  data 
present  in  the  raw  weather  data  files.  The  reduced  data  files  were  converted  to 
a  Foxbase  data  base  format  and  merged  with  the  MASTER  data  base  (see  appendix  C) . 
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WXmmddyy.Fix 

Data! 

WXmmddyy . DAT 
Datai 

STLmmm.DAT 


■■>  Freprocessed  and  corrected  weather  data  file 
(See  A. 1.4) 

-“>  Weather  data  for  one  day  in  Foxbaae  data  base  compatible 
format 
(See  A. 1.4) 

**■>  Weather  data  for  one  month  (mmm  *  Jan,  Feb,  etc.) 
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APPENDIX  B 


DATA  REDUCTION 

The  data  collected  at  the  site  were  brought  back  to  the  Federal  Aviation 
Administration  (FAA)  Technical  Center  where  it  was  reduced  to  a  form  to  be  used 
in  the  final  analysis.  Unpacking  was  the  process  whereby  data,  recorded  in  a 
foreign  format  for  purposes  of  space  and  efficiency,  was  converted  to  a  format 
compatible  with  the  analysis  environment.  Reduction  was  the  process  of 
coordinate  conversion,  filtering,  smoothing,  and  interpolation  of  the  unpacked 
radar  data.  Each  of  the  raw  data  files  identified  in  appendix  A  had  to  be 
unpacked.  The  unpacking  and  reduction  procedures  are  described  here. 

B.l  SRAP  AND  INTERFACILITY  DATA. 

The  radar  data  collected  via  the  Sensor  Receiver  and  Processor  (SRAP)  required 
considerably  more  processing  than  any  other  type  of  data  collected  to  prepare  it 
for  analysis.  Unpacking  and  reduction  of  the  radar  data  involved: 

a.  Conversion  to  engineering  units  and  sorted  according  to  beacon  code. 

b.  Deletion  from  further  processing  if  any  of  the  following  were  detected; 
large  gap(B)  in  the  track,  track  was  of  short  duration,  or  no  Mode  C  altitude  and 
altitude  can't  be  had  from  other  sources. 


c.  Conversion  to  (time,  x,y,z),  then  translation  and  rotation  to  the  runway 
threshold  being  approached. 

d.  Filtering  and  smoothing  of  radar  data  to  eliminate  radar  outliers  and  to 
obtain  a  more  accurate  estimate  of  aircraft  position. 


e.  Interpolation  to  attain  estimates  of  cross-track  deviation  at  specific 
points  along  the  Instrument  Landing  System  (ILS)  approach. 


The  following  software  programs  performed  these  processes  on  the  raw  SRAP  data 
with  the  following  results. 

B.1.1  TRACKS. FOX. 


— >  language:  Foxbase  -4-2.10  programming  language 


— >  input: 


a.  Smddhhmm.DAT  (raw  SRAP  data  file) 

b.  Imddhhmm.AOL  (raw  Interfacility  data  file) 


— >  process: 


a.  Invoked  SRAPUNPK.PAS  to  unpack  raw  SRAP  data  and 

produced  SRAP  Foxbase  data  base  file  Smddhhmm.DBF 

b.  Indexed  Smddhhmm.DBF  by  session  and  beacon  code 

c.  Identified  tracks  with  sufficient  number  of  scans 

d.  Determined  runway  being  approached  for  each  track 

e.  Cross  referenced  SRAP  data  with  interfacility  data  file 

Imddhhmm.AOL  to  obtain  aircraft  ID  (ACID)  and  aircraft 
type  (ACTYPE)  for  each  beacon  code 
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>  outputs 


SRAPUNPK . PAS . 

>  languages 

>  Inputs 

>  process: 

>  output: 

■  gftfst.fi* 

>  languages 

>  inputs: 

>  process t 


->  outputs: 

PTTRANS.C. 
->  language: 
->  inputs: 

->  process: 

~>  outputs: 


f.  Appended  a  record  to  the  master  data  base  (MASTER. DBF) 
for  each  identified  track  (see  appendix  C) 

a.  created  directory  "Smddhhntm"  and  placed  ASCII  aircraft 

track  files  ^acid.RWY  for  SRAPO  into  this  directory 
(see  A. 2) 

b.  Appended  one  record  for  each  identified  track  to  the 

MASTER  data  base  (see  appendix  C) 


Turbo  PASCAL  5.0 

Smddhhmm.DAT  (raw  SRAP  data  file) 

Unpacked  beacon  and  radar  reinforced  beacon  messages  only 
Smddhhmm.DBF  (Foxbane  data  base  format) 


Turbo  C  2.0 

a.  All  _acid.rwy  files  (raw  track  files) 

b.  MASTER. DBF  master  data  base  (optional,  depends  on 

version  of  GAP.C) 

a.  Deleted  illegal  multiple  scans 

b.  Added  missed  altitudes 

c.  Altitude  correction  based  on  airport  altimeter  setting 

d.  Identified  large  time  gaps  and  determined  if  the  pre-gap 

and  post-gap  data  are  from  the  same  track 

e.  Produced  documentation  explaining  results 

@acid.rwy  (SRAPO)  corrected  track  files  (A. 2.1) 

Sacid.rwy  (SRAPO)  documentation  files  (A. 2.1) 


Turbo  c  2.0 

All  Sacid.rwy  files  (corrected  track  files) 

a.  Converted  data  from  (rng,az,alt)  to  (x,y,z) 

b.  Translated  data  to  runway  threshold  identified  in 

filename 

fiacid.rwy  (SRAPO)  translated  and  corrected  track  files 
(A. 2.1) 
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— ■>  languages 
— >  inputs s 
— >  process: 

— >  outputs: 

B.1.6  SPLINE. C. 
— >  language: 
— >  inputs: 

— >  process: 


Turbo  c  2.0 

All  fiacid.rwy  files  (translated  and  corrected  track  files) 

Filtered  and  smoothed  using  Lincoln  Lab's  radar  smoothing 
algorithms 

'acid.rwy  (SRAPO)  filtered,  smoothed,  translated,  and 
corrected  track  files  (A. 2.1) 


Turbo  C  2.0 

All  ‘acid.rwy  files  (filtered,  smoothed,  translated,  and 
corrected  track  files) 

Inserted  an  interpolated  data  point  (time,x, y, z)  at  each 
0.15  run!  X  increment 


— >  outputs:  (acid.rwy  (SRAPO)  interpolated,  filtered,  smoothed, 

translated,  end  corrected  track  files  (A. 2.1) 

B.2  DASI  DATA. 

The  raw  DASI  data  were  processed  by  the  following  programs  with  the  described 
results. 


-8*2.1  RCMSUPy.PA_S. 


— >  language: 
— >  inputs: 

— >  process: 
— >  outputs: 


Turbo  pascal  5.0 

Smddhhmm.RCM  (raw  RCMS  data  file) 

Unpacked  DASI  data  and  put  it  into  a  Foxbaoe  data  base  format 
Rmddhhmm . DBF  (unpacked  DASI  data  in  foxbane  format) 


B. 3  WEATHER  DATA. 


The  weather  data  for  Lambert-St.  Louis  International  Airport  (STL)  required  some 
preprocessing  before  it  could  be  unpacked  by  the  weather  data  unpacking  program, 
STLWX.BAS.  The  weather  data  preprocessing  and  unpacking  procedures  are  described 
here. 


Preprocessing  a  weather  data  file  consisted  of: 

a.  Removed  correction  weather  reports  and  blank  lines  between  weather 
reports. 
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b.  Added ,  if  necessary,  a  ")"  to  the  end  of  the  weather  data  file  ae  an  End 
of  rile  marker  (107). 

o.  Checked  that  the  firet  line  of  each  weather  report  had  at  least  one 
in  it.  STLWX.BAS  needed  at  least  one  "/"  in  the  first  line  of  a  weather  report 
to  process  that  report  properly. 

Unpacking  the  preprocessed  weather  data  files  created  one  Foxbase  data  base 
compatible  file  for  each  day  and  one  7oxbase  data  base  compatible  file  for  each 
month  of  weather  data  files. 


B.3.1  CORRECT. BAS. 
— >  language: 

— >  input: 

— >  process: 


— >  output: 

Bt.3,2  aiASHuB&a. 

— >  language: 
— >  input: 

— >  process: 

— >  output: 

B.3.3  STLWX.BAS. 
— >  language: 
— >  input: 

— >  process: 


Turbo  BASIC  1.0 

WXmmddyy.TXT  (raw  weather  data  file) 

a.  Kept  last  correction  weather  report  in  data  file,  all 

previous  correction  reports  and  the  original  report 
were  removed  from  the  weather  data  file 

b.  Removed  blank  lines  between  weather  reports  in  a  file 

c.  Added,  if  needed,  a  ")”  to  the  weather  data  file  as  an 

EOF  marker 

WXmmddyy . FIX  (corrected  weather  data  files) 


Turbo  BASIC  1.0 

WXmmddyy. FIX  (corrected  weather  data  file) 

Counted  the  number  of  "/"  in  first  line  of  each  weather 
report 

WXmmyy.BAD  (listing  by  time  for  each  ".FIX”  file  of  weather 
reports  with  less  than  five  "/"  in  their  first  line) 


Turbo  BASIC  1.0 

WXmmddyy. FIX  (corrected  weather  data  file) 

Unpacked  a  weather  data  file  to  produce  a  Foxbase  data  base 
compatible  record  for  each  weather  report  and  reordered 
records  by  time  and  date  in  ascending  order  in  the  output 
files 
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— >  outputs 


WXmmddyy.DAT  (unpacked  weather  data  file) 

STLmmm.TOT  ( combined  WXmmddyy . DAT  files  for  one  month,  where 
mmm  -  JAM,  FEB,  MAR,  eto.) 


B.3.4  STRU.DBF. 

— >  languages  Foxbase  +2.10  programming  language 

— >  inputs  STLmmm.TOT  (combined  WXmmddyy.DAT  files) 


— >  process s  STRU.DBF  was  a  data  base  structure  with  fields  for  the  data 

contained  in  a  weather  report,  it  was  copied  to  WXjnmm.DBF. 
The  data  in  tha  STLmmm.TOT  file  was  then  added  to 
WXjnmm.DBF  using  the  Foxbase  APPEND  command. 

— >  outputs  WXjnmm.DBF  (weather  data  for  1  month  in  Foxbase  data  base 

format ) 


Certain  weather  data  base  fields  were  next  merged  with  the  Master  Data  base  (see 
appendix  C) . 


B. 4  PARROT  TRANSPONDER  DATA. 

Parrot  data  statistics  were  extracted  from  the  raw  SRAP  data,  to  assist  in  the 
calculation  of  the  radar  range  and  azimuth  biases,  using  the  program  described 
below. 


B.j.l  .TC_PAB.OT-.EgX. 


— >  languages  Foxbase  +2.10  programming  language 


— >  input:  Smddhhmm . DBF  (Foxbase  data  base  format) 

— >  process:  Collected,  unpacked,  analyzed,  and  produced  a  statistical 

report  on  the  quantity  and  quality  of  the  Parrot 
transponder  data 


— >  output:  A  printout  of  a  report  containing  values  for  the  mean  and 

standard  deviation  of  both  range  and  azimuth,  and  the  ACP 
skewness  and  kurtosiB  of  the  azimuth 
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MASTER  DATA  3ASE 

Prior  to  data  analysis  all  unpacked  data  were  merged  into  a  data  base  that 
identified  each  approach  collected.  This  data  base  was  referred  to  as  the  MASTER 
data  base.  Data  used  to  construct  the  MASTER  data  base  consisted  of  information 
about  each  track  and  the  weather  at  the  time  of  the  track's  collection.  The 
MASTER  data  base  did  not  contain  the  tracks'  radar  position  data  however.  The 
radar  position  data  for  each  track  was  instead  stored  in  the  individual  track 
files  (refer  to  A. 2.1). 

The  MASTER  data  base  contained  one  record  for  each  approach.  The  record  had  a 
field  for  each  track  characteristic.  Since  the  format  of  the  MASTER  data  base 
was  developed  for  an  earlier  data  collection  effort,  there  were  some  fields  in 
the  data  base  not  used  for  the  Lambert-St.  Louis  International  Airport  (STL)  data 
collection  effort. 

C.l  MASTER  DATA  BASE  FIELDS. 

For  purposes  of  clarity  all  the  MASTER  data  base  record  fields  are  shown  on  a 
single  page  in  figure  C.l. 

C.2  MASTER  DATA  BASE  GENERATION. 

The  MASTER  data  base  (^MASTER. DBF)  was  generated  in  a  multistep  process,  only 
the  following  fields  were  used  in  the  STL  data  collection. 

Field  Description 

1  Test  or  session  name  (e.g.,  S2131453) 

2  SRAP  channel  #  (0  or  1) 

3  Aircraft  ID  (e.g.,  UAL9253), 

4  User  type  (Military,  Commercial,...) 

5  Aircraft  type  (e.g.,  B727) 

6  Beacon  code  (0000  thru  7777) 

7  Month/day/year  of  collection 

8  Time  of  day  of  first  scan  for  the  track 

9  Time  of  day  of  last  scan  for  the  track 

10  Altitude  of  first  scan  for  the  track 

11  Altitude  of  last  scan  for  the  track 

12  Number  of  scans  for  the  track 

13  Runway  beim;  approached 

28  Temperature  in  degrees  fahrenheit  during  track 

29  Dewpoint  in  degrees  fahrenheit  during  track 

30  Ceiling  type  (M  or  E  or  W) 

31  Ceiling  height  in  feet 

32  Visibility  in  nautical  miles 

33  Weather  (Fog  and/or  Rain  and/or  Snow,...) 

34  Wind  speed  in  knots 

35  Wind  direction  in  degrees  from  true  north 

42  Barometric  pressure  in  inches  of  mercury 

43  Distance  X  at  which  A/C  is  stabilized  on  localizer 
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ZiSlll 

rma  Mum? 

Type  Lsnoth 

Description 

1 

SESSION 

Chr 

8 

Teet  name  (e.g.,  S2131453)  (See  A. 1*1) 

2 

CM 

Num 

1 

Channel  #  (0  off  1)  of  SRAP 

3 

AC_ID 

Chr 

7 

Aircraft  ID  (e.g.,  UAL9253) 

4 

USER_TYPE 

Chr 

1 

Uaer  type  (Military  or  Commercial  or  ...) 

S 

AC_TYPE 

Chr 

5 

Aircraft  type  (e.g.,  B727) 

6 

BEACON 

Chr 

4 

Beacon  code  (0000  thru  7777) 

7 

DATE 

Date 

8 

Month/day/year  of  collection 

8 

STAHT_TIME 

Chr 

11 

Time  of  day  of  firat  acan  for  the  track 

9 

STOP_TIME 

Chr 

11 

Time  of  day  of  laat  acan  for  the  track 

10 

START_ALT 

Num 

6 

Altitude  of  firat  acan  for  the  track 

11 

ST0P_ALT 

Num 

6 

Altitude  of  laat  acan  for  the  track 

12 

TARGET_CT 

Num 

4 

Number  of  acana  for  the  track 

13 

RUNWAY*"* 

chr 

3 

Runway  being  approached 

14 

MIN_X 

Num 

8 

Minimum  diatance  from  threahold 

IS 

T_AT_4_NMI 

Chr 

11 

Time  of  day  at  4  rani  from  threahold 

16 

MAX_Y_TNT2 

Num 

6 

Maximum  lateral  deviation  from  ILS  towards  NTZ 

17 

XMAXY_TNTZ 

Num 

8 

Distance  from  threshold  at  MAX_Y_TNTZ 

18 

MAX_Y_ANTZ 

Num 

6 

Maximum  lateral  deviation  from  ILS  away  from  NTZ 

19 

XMAXY~ANTZ 

Num 

8 

Diatance  from  threahold  at  MAX_YuANTZ 

20 

MAXZ 

Num 

6 

Maximum  altitude  for  the  track 

21 

MINZ 

Num 

6 

Minimum  altitude  for  the  track 

22 

MEANT 

Num 

6 

Average  ILS  deviation  from  stabilization  to  TD 

23 

MEAN_XDOT 

Num 

8 

Average  velocity  of  A/c  during  ILS  approach 

24 

STD_DEV  Y 

Num 

6 

Standard  deviation  of  ILS  lateral  deviation 

25 

INNTZ 

Log 

1 

.TRUE,  if  A/C  in  NTZ  after  stabilization 

26 

NTZ_DIS 

Num 

6 

Width  of  NOZ  in  feet 

27 

X_AT_VlO 

Num 

8 

Distance  from  threahold  at  firat  NTZ  violation 

28 

TEMP 

Num 

3 

Temperature  in  degrees  fahrenheit  during  track 

29 

DEWPT 

Num 

3 

Dewpoint  in  degrees  fahrenheit  during  track 

30 

CEILJTYPE 

Chr 

1 

Ceiling  type  (M  or  e  or  W) 

31 

CEILING 

Num 

5 

Ceiling  height  in  feet 

32 

VISIBILITY 

Num 

5 

Visibility  in  nmi 

33 

WEATHER 

Chr 

4 

(Fog  and/or  Rain  and/or  Snow  and/or  ...) 

34 

WIND_SPEED 

Num 

2 

Wind  speed  in  knots 

35 

WINDDIR 

Num 

3 

Wind  direction  in  degrees  from  true  north 

36 

LLWAS_SPD 

Num 

2 

Low  level  windshear  alert  ayatem  speed  in  knots 

37 

LLWAS~DIR 

Num 

3 

Low  level  windahear  alert  system  direction  deg 

38 

LLWASJ3UST 

Num 

2 

Low  level  windahear  alert  system  gusts  in  knots 

39 

CFA_SPD 

Num 

2 

Low  level  windahear  alert  system  center  field  ws 

40 

CFADIR 

Num 

3 

Low  level  windshear  alert  system  center  field  wd 

41 

RVR 

Num 

4 

Runway  visual  range  in  feet 

42 

BRMTR 

Num 

5 

Barometric  pressure  in  inches  of  mercury 

43 

STBLX 

Num 

5 

X  at  which  A/C  is  stabilized  on  localizer 

44 

PAIR~LDR 

Chr 

7 

Leading  adjacent  localizer  AC_ID  (if  it  exists) 

45 

PAIR_TRL 

Chr 

7 

Trailing  adjacent  localizer  AC_ID  (if  it  exists) 

46 

GAP_START 

chr 

11 

Raw  track  file  start  time  (as  determined  by  GAP) 

47 

GAP~STOP 

Chr 

11 

Raw  track  file  stop  time  (as  determined  by  GAP) 

48 

GAPwSTRT_R 

Num 

6 

Raw  track  file  initial  range 

49 

GAP~STOP~R 

Num 

6 

Raw  track  file  final  range 

50 

GAP~NUM  “ 

Num 

3 

Number  of  scans  in  raw  track  file 

51 

GAP~MS_SCN 

Num 

3 

Number  of  missing  scans  in  raw  track  file 

52 

GAP~DOUBLE 

Num 

3 

Number  of  double  scans  in  raw  track  file 

53 

GAP~ALT 

Num 

3 

Number  of  missing  or  unreasonable  altitudes 

Total  of  282  bytea/record 


FIGURE  C-l.  MASTER  DATA  BASE  RECORD  STRUCTURE 
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The  processes  that  generated  the  MASTER  data  bane  are  identified  and  described 
in  the  following  paragraphs) 


C. 2 . 1  TRACKS. FOX. 

TRACKS. FOX  was  the  same  process  identified  and  partially  described  in  B.1.1.  In 
addition  to  the  identification  and  unpacking  of  the  individual  track  files,  it 
also  appended  one  record  to  the  MASTER  data  base  for  each  track.  TRACKS. FOX 
filled  in  data  fields  1  through  13t  (1)  session,  (2)  channel,  (3)  ACID,  (4)  user- 
type,  (5)  A/C-type,  (6)  beacon  code,  (7)  date,  (8)  start  time,  (9)  atop  time, 
(10)  start  altitude,  (11)  stop  altitude,  (12)  target  count,  and  (13)  runway  for 
each  aircraft  track. 

C.2.2  WX  APP.FOX. 

This  process  appended  fields  (28)  temperature,  (29)  dewpoint,  (30)  ceil_type, 
(31)  ceiling,  (32)  visibility,  (33)  weather,  (34)  wind  speed,  (35)  wind 
direction,  and  (42)  barometer  pressure  by  time  and  date  to  records  in  the  MASTER 
data  base. 

— >  inputs  WX_mmm.DBF  (weather  data  base  files,  see  B.3.4) 

— >  process s  Merged  fields  from  weather  data  base  with  the  appropriate 

fields  in  the  MASTER  data  base 

-->  outputs  Modified  MASTER  data  base  weather  fields  cited  above 

C.2.3  STABLE_X. 

STBL_X  (43)  was  the  distance  from  the  end  of  the  runway  on  the  X  axis  at  which 
the  approaching  aircraft  is  considered  stabilized  on  the  localizer.  This  value 
was  not  calculated  for  STL  tracks.  However,  a  value  was  needed  in  this  field  to 
run  analysis  software;  for  this  purpose  a  value  of  4  nmi  was  used. 
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STL  DATA  COLLECTION  REFERENCE  MANUAL 
D.l  SR/.P  DATA  COLLECTION. 

The  automatic  Senior  Receiver  and  Processor  (SRAP)  data  collection  software  ran 
at  the  Lambert-St.  Louis  international  Airport  (STL)  Terminal  Radar  Approach 
Control  (TRACON)  in  support  of  the  Visual  Approaches  Data  Collection  Project 
(F20-06G) .  The  data  collection  software  consisted  of  various  programs  invoked 
by  a  batch  file  on  the  SRAP  data  collection  computer  (IBM  PC  XT).  The  batch 
file,  RUN_STLV.BAT,  was  initiated  from  the  AUTOEXEC.BAT  file  after  the  computer 
was  rebooted  each  morning.  The  batch  program  initiated  the  following  steps. 

D.1.1  INITIALIZE  DOS  CLOCK. 

ASTCLOCK.COM  was  an  off-the-shelf  program  used  to  initialise  DOS  time  to  the  time 
kept  by  the  clock  on  the  AST  board. 

P.1.2  WAIT  PROGRAM. 

WAIT0600. PRG  was  an  ACD-340  written  Foxbase  program  which  looped  until  the  DOS 
time-of-day  was  between  0600  and  2200  hours.  WAITOt-OO.PRG  than  terminated  and 
allowed  RUN_STLV.BAT  to  continue. 

D.l. 3  BATCH  FILE  CREATION. 

RUN_STLV.BAT  immediately  started  FILENAME. PRG.  FILENAME. PRG  was  an  ACD-340 
written  Foxbase  program  which  created  two  batch  files  (FILENAME.BAT  and 
DELE_CHK.BAT).  These  files  renamed,  copied,  and  deleted  the  data  collection 
files  after  SRAP  data  collection  ended.  The  filenames  created  by  FILENAME. PRG 
were  based  on  the  current  date  and  time  of  day  in  order  to  uniquely  identify  the 
daily  SRAP  data  collection  files.  For  more  information  on  these  batch  files  see 
D. 1 . 3 ,  D.l. 4. 2,  and  D. 1.4.4. 

D.l. 4  DATA  COLLECTION  PROGRAM. 

FASTSRAP.EXE  was  an  ACD-340  written  8088  assembly  language  program  which 
collected  and  stored  SRAP,  DASI,  and  message  data  (SRAP.DAT,  RCMS.DAT,  and 
MESS . DAT )  to  the  C:\DATA  subdirectory.  For  more  information  on  the  SRAP  and  DASI 
data  files  see  A. 1.1  and  A. 1.3.  The  message  data  file  was  a  listing  of  messages 
generated  by  FASTSRAP.EXE  during  execution,  these  messages  were  not  used  during 
the  data  analysis.  FASTSRAP.EXE  ran  from  whenever  it  was  started  until  2200 
hours  (Central  time). 

D . 1 . S  BREAKOUT  AREA ♦ 

WAIT10.COM  was  an  off-the-shelf  program  that  waits  10  seconds.  This  gave  an 
interactive  user  a  chance  to  halt  RUN_STLV.BAT  aft er  FASTSRAP.EXE  terminated. 
RUN_STLV.BAT  would  have  to  be  halted  if  an  error  occurred  during  the  execution 
of  FASTSRAP.EXE. 

D.1.6  FILE  TRANSFER. 

After  data  collection  terminated  the  IBM  XT  attempted  to  log  on  to  the  network 
and  then  initiated  FILENAME.BAT.  FILENAME.BAT  renamed  the  SRAP,  DASI,  and 
message  data  files,  created  by  FASTSRAP.EXE,  to  Smddhhmm.DAT,  Smddhhmm. RCM,  and 
Smddhhmm.MES,  respectively  (for  more  information  on  "mddhhmm"  see  A. 1.1  ). 
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FILENAME .  BAT  than  cheeked  that  the  network  wee  up,  if  eo,  then  it  copied  the 
renamed  SRAP,  DASI ,  and  meesage  data  files  to  the  Js\STL\DATA  directory. 


D.1.7  FIL1  BACKUP . 

The  file  backup  process  consisted  of  a  wait  program,  a  Primary  backup,  a 
Secondary  backup,  and  delation  of  old  SRAP  data  files.  After  this,  the  SRAP  data 
files  ware  deleted  from  the  Ct \DATA  subdirectory  only  if  they  were  successfully 
copied  to  the  network  Jt  drive  when  FILENAME.BAT  executed. 

ttiii-U. _ HaJLfcJtegggaffi* 

WAIT0005 . PRO  was  an  ACD-340  written  Foxbase  program  which  loops  until  DOS  time 
is  between  12t05  a.m.  and  12t30  a.m.  Xt  then  terminated,  allowing  RUN_STLV.BAT 
to  perform  the  tape  backup. 

D.1.7. 2  Taoe  Backup. 

TAPEBACK.BAT  accomplished  a  tape  backup  by  invoking  TAPSBCK1.BAT.  TLPEBCKl . BAT 
performed  a  Primary  and  Secondary  backup  of  the  SRAP  and  interfacility  data  files 
in  the  J:\STL\DATA  subdirectory  which  had  not  been  backed  up  previously;  i.e., 
those  files  that  had  their  archive  bit  set.  If  the  IBM  XT  did  not  successfully 
log  on  to  the  network,  TAPEBCK1.BAT  would  backup  the  data  present  on  the  C:\DATA 
subdirectory.  The  primary  tape's  subdirectory  was  stored  in  the  C:\DATA\BACKUP 
subdirectory  as  TAPEDIR1.TXT.  The  secondary  tape's  directory  was  then  stored  in 
C:\DATA\BACKUP  subdirectory  as  TAPEDIR2.TXT. 

Stir 7. .3 _ Deletion  of  SRAP  Lata  Files  on  CsVDATA . 

TAPEBACK.BAT  also  invoked  DELE_CHK.BAT.  DELE_CHK.BAT  checked  that  the  day's  SRAP 
data  files  were  successfully  copied  to  the  Js  drivo  (see  D.i.3).  If  the  file>; 
existed  on  Ji  then  DELE_CHK.BAT  went  ahead  and  deleted  those  day's  SPAP  data 
files  from  the  C:\DATA  subdirectory.  Any  additional  data  files  in  the  Ci\DATA 
subdirectory  were  copied  to  the  C;  \DATA\ BACKUP  subdirectory.  This  saved  any  SRAP 
data  files  created  before  a  system  crash,  but  not  previously  backed  up.  The 
C:\DATA\BACKUP  eubdirectory  was  checked  weekly  for  data  files,  any  files  found 
were  copied  to  the  J:\STL\DATA  subdirectory  and  then  deletrd  from  the  IBM  XT  C: 
drive. 


D.1.8  RESET  AST  CLOCK. 

ASTCLOCK.COM  was  used  to  reset  the  clock  on  the  AST  board  to  DOS  time  (DOS  time 
was  set  to  wwvb  time  at  the  beginning  of  data  collection) . 

P.1.9  STSTEM  REBOOT. 

After  the  tape  backup  process  was  completed  in  the  early  morning  hours, 
REBOOT.COM  was  executed.  REBOOT.COM  was  an  off-the-shelf  program  used  to  perform 
a  soft  reboot  of  the  IBM  XT.  The  IBM  XT  was  rebooted  to  remove  any  Terminate  and 
Stay  Resident  (TSR)  programs  initiated  when  the  system  logged  on  to  the  network. 
After  the  system  rebooted,  RUN  STLV.BAT  was  restarted. 
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The  following  is  an  explanav.  ion  of  the  Landrum  &  Brown  (L&B)  ARTS  I  Dent  if  ioation 
Data  Acquisition  System  (ID-DAS)  software  which  ran  at  the  STL  TRACON.  This 
process  was  invoked  by  ISTL_RUN.BAT  on  the  Interfacility  data  collection  computer 
(IQ-Plus  XT  compatible).  ISTL_RUN.BAT  was  initiated  by  an  appointment  scheduling 
program  each  morning  at  0S00  (Central  time) .  Interfacility  data  collection  began 
1  hour  before  SRAP  data  collection  because  of  the  possibility  of  up  to  1  hour 
difference  between  the  receipt  of  interfacility  data  for  an  aircraft  and  that 
aircraft's  arrival  time.  The  batch  program  initiated  the  following  steps. 

D.2.1  DELETION  OF  OLD  INTERFACILITY  DATA  FILES. 

DOS  code  was  used  to  check  for  the  presence  of  Interfacility  data  files 
( imddhhmm.AOL,  see  A. 1.1)  on  the  C:\AOL  subdirectory.  If  data  files  were 
present,  they  were  deleted  from  Ct\AOL. 

D.2.2  DATA  COLLECTION  PROGRAM. 

IDPTC.EXE  was  the  executable  program  IDentif ication  Processo.v/TC  that  collected 
and  stored  the  interfacility  data  to  the  C:\AOL  subdirectory.  IDPTC.EXE  always 
started  interactively.  IDP.INP  was  a  redirected  input  ASCII  file  containing  the 
responses  needed  to  initialize  IDPTC.EXE.  The  responses  are  explained  belowt 

Processing  mode  *  ARRIVALS 
Include  all  aircraft  ID's 

Copy  all  ARTS  Interfacility  (IF)  messages  pertinent  to  ID-DAS 
to  a  buffer  file 
Processing  title 
Specify  Start  and  Stop  time 

Begin  data  collection  immediately  upon  program  execution 
Specify  Stop  time 
Stop  time  *  2200  hours 

Output  filename  for  buffer  file  (STL.AOL) 

Sets  default  output  filename  for  data  file  (default 
imddhhmn.ADL) 

C:\AOL\STLDATA  File  root  for  buffer  file 

D.2.3  FILE  BACKUP. 

The  daily  Interfacility  data  file  was  backed  up  on  the  C:\AOL\ARRIVALS 
subdirectory  and  the  J:\STL\DATA  subdirectory.  Interfacility  data  files  in  the 
J:\STL\DATA  subdirectory  were  later  backed  up  on  tape  along  with  SRAP  data  files. 

D . 3  WEATHER  DATA  COLLECTION. 

The  following  is  an  explanation  of  the  STL  Weather  Data  collection.  The  process 
was  invoked  by  STL. BAT  running  on  an  IBM  compatible  computer  located  at  the  FAA 
Technical  Center.  STL.3AT  was  initiated  by  an  appointment  scheduling  program 
each  day  at  2350  hours  Eastern  time  (2250  hours  Central  time).  The  batch  file 
executed  software  that  logged  onto  the  Kavouras  weather  network,  requested  the 
previous  30  STL  weather  reports,  and  Baved  these  reports  to  a  data  file 
(WXnunddyy.TXT,  see  A. 1.3).  The  batch  program  consisted  of  the  following  steps. 
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PCWX  started  the  communication*  program  that  accessed  tha  Xavouras  Waathar  Data 
Base.  PCWX  waa  aat  up  to  dial  up  tha  waathar  data  base#  log  oh  to  tha  data  base, 
and  to  opan  up  a  captura  buffer  for  any  racaived  data  upon  execution.  Uaing  the 
"EVENT"  option,  PCWX  sent  the  command  "SA/RPTS-30  STL"  at  23SS  hours.  After  the 
weather  reports  were  received,  they  were  saved  to  a  weather  data  file.  PCWX  then 
automatically  logged  off  the  Kavouras  Weather  Data  Base  and  exited  to  DOS. 


That  day's  collected  weather  data  file  waa  copied  to  the  C:\WEATHER\STL_RPTS 
subdirectory.  The  data  file  would  be  backed  up  to  a  Network  drive  by  PAA 
technical  personnel  the  following  day. 


DOS  code  was  used  to  check  for  the  presence  of  old  weather  data  files  in  the 
C : \ WEATHER  subdirectory.  If  data  files  were  found,  they  were  deleted  from 
C: \ WEATHER. 
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